Ever since Covid impacted the world, many locations faced in-person rate limitations in an effort to reduce the contagiousness of the virus. The SFU Surrey Badminton Club (SSBC) was not spared in the process. Despite the pandemic fading away into a memory of the past, a rate limit of 25 person / session is still imposed as part of the hosting facility's guideline to maintain a safe operating space for all students and occupants. Meanwhile, the demand for recreational fitness and sports sessions, as well as the craving for in-person socialization, resulted in booming demand for the weekly badminton sessions where we saw as many as 50 people interested per week. In an effort to keep track of the priority list of students, alumnus, and drop ins, a digital Google Sheet was used to record sign ups in order to maintain a fair application status for all that are interested. I saw the repetitiveness of the weekly sign up ordeal where the current Presidents must validate who is coming the day of to notify waitlisted members, as well as the need to verify the attendance of those who put their name down while guaranteeing that no one signed up for more than themselves, and thought: I wonder if automation has a role to play in reducing the workload here. That is when I envisioned an automated waitlist solution to handle the reoccurring tasks on a weekly basis with minimal human oversight.

The premise of the solution would take inputs from club members on Discord, the main communication platform for SSBC, to sign up automatically on either the reserved spots or waitlist, where the list can be easily validated and refreshed when the weekly session is over. A priority queue was the obvious choice of design here, given that current student's attendance takes precedence over alumnus and drop-ins as per the rules of the club.

Interface

The user facing portion of the service was made using discord.py, where commands are role dependent. Club Executives can sudo override the waitlist status, while users have access to the basic command of registering, un-registering, showing the current queue status, as well as showing the common command list.

The sign ups are further categorized based on the type of sign ups received, where 20 spots are dedicated for students, and open to public if not filled up by the students on the last day, while the sign up list is reset when the weekly sessions starts, both being scheduled as tasks in order to require minimum input from the executives.

Hosting

Initially the server choice was Heroku based on my previous pleasant experience with the platform, however I soon realized that Heroku's free tier was ending shortly and was thus unsustainable as a long term low cost solution. Google Cloud Platform was then chosen as the hosting server and was easily set up with complementary starting credits.

Data

Given that I wanted highly scalable real time data changes to reflect for all users simultaneously for up to 500 users, which provided a safety margin to the club's verified user list for the year, Firebase Realtime Database was the first choice that came to mind. With their detailed documentation and easily configurable APIs, it was straight forward to set up two priority queues that can be manipulated based on the user's role.

I am really happy with how the project turned out, and how I got the opportunity to utilize my Full Stack knowledge to reduce the strain on the club's current executives. Once I completed end to end testing for the service, I then handed it off to the current President/Software Developer for the club.